Various compression schemes today enable compression and decompression of network packet headers. Many such schemes are optimized for packet transfers over wired, bandwidth-restricted networks, such as telephone networks (via modem connections). These schemes generally do not take into account specific peculiarities of wireless networks, such as higher error rate tolerance to ensure successful packet transfers. High error rates may, however, significantly degrade the performance of traditional header compression schemes.
To specifically address the characteristics of wireless networks, the Internet Engineering Task Force (“IETF”) recently developed a header compression standard compatible with wireless networks. Known as Robust Header Compression (“ROHC,” IETF RFC 3095, July 2001), the standard focuses on compressing packet headers for a variety of network packets on wireless networks. Thus far, “profiles” have been defined for applying ROHC to Internet Protocol (“IP”) packets, Real-Time Protocol (“RTP”) packets, User Datagram Protocol (“UDP”) packets and Transport Control Protocol (“TCP”) packets. Profiles are schemes or protocols that define how compression is performed on various network packets.
Similar to other compression schemes, ROHC is generally applied “hop-by-hop,” namely at every node on the network. In other words, when a node receives a compressed packet header, it decompresses the packet header, examines the header fields, and recompresses the packet header for transfer to the next node on the network. These steps may be performed at every node on the network in between the source node (where the packets originate) and the destination node (the ultimate destination for the packets).
In addition to compression, security protocols are also commonly applied to network packets. Internet Protocol Security (“IPSec,” IETF RFC 2401, November 1998) is a set of security protocols developed by the IETF to provide security services at the IP layer of a network. IPSec provides two protocols for security, namely the IP Authentication Header (“AH”) protocol and the Encapsulating Security Payload (“ESP”) protocol. AH may provide connectionless integrity, data origin authentication and optional anti-replay services while ESP may provide encryption, limited traffic flow confidentiality, connectionless integrity, data origin authentication and anti-replay services.
IPSec-protected IP packets may be transmitted in either “transport mode” and/or “tunnel mode.” Transport mode transmission may be used for secure transmission of an IP packet from a source node directly to its ultimate destination node, without any intermediate security devices, e.g. between two peer nodes. Tunnel mode, on the other hand, is typically used when the packet from a source node has to traverse through additional security devices such as security gateways (including one or more routers, firewalls and/or other network devices) prior to arriving at the destination node. Tunnel mode may also be used to hide the flow details of the packet because only the tunnel entry and exit points are visible to anyone who may intercept the packet.
In contrast to ROHC, IPSec is not applied hop-by-hop, but rather “end-to-end.” In other words, an IPSec protected packet is generally encoded on the source node and decoded on the destination node (or on the security gateway, in tunnel mode). The IETF mandates the use of IPSec for all networks conforming to IPv6 (IETF RFC 1883, December 1995) and MobileIPv6 (IETF MobileIPv6, Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In Progress), September 2002) standards, and recommends the use of IPSec for all networks conforming to the IPv4 (IETF RFC 2401, November 1998) and MobilIPv4 (IETF RFC 3220, January 2002) standards. As a result, IP packets transmitted over any network today are most likely protected by IPSec protocols.
Unfortunately, there are no IETF profiles for applying ROHC to IPSec protected packets today. In other words, IPSec-protected IP packets may not currently be compressed. This inability to compress IPSec-protected IP packets is becoming increasingly problematic. IP packet headers have increased in size as new IP protocols have been introduced. For example, the IPv6 standard increased IP packet header sizes by almost fifty percent. Additionally, the introduction of the “v4-v6 tunneling” concept to ensure compatibility between IPv4 and IPv6 compliant networks has added significant overhead to IP packet headers. Mobile IP protocols have also introduced additional IP packet headers, thus contributing to the inflation of IP packet size.
As a result, there is a need to be able to compress IP packets, and more specifically IPSec-protected IP packets. The IETF has recently discussed the possibility of using a compression scheme called “IPComp” to enable header compression of IPSec-protected IP packets. IPComp, however, suffers from a number of shortcomings. Most importantly, IPComp is a general-purpose compression scheme, designed for data compression. As a result, IPComp provides only limited compression gains for packet header compression, as compared to ROHC, which is optimized for packet header compression and may achieve between eighty and/or ninety percent compression efficiency. This difference in compression efficiency also results partially from the inherent characteristics of these two compression schemes. IPComp is a “stateless” scheme, i.e., it compresses and decompresses each IP packet by itself, without any relation to other packets. In contrast, ROHC is a “stateful” compression scheme, which is more complex because it retains additional information regarding each IP packet, but may also achieve a higher degree of compression.